CbmRoot: Simulation and Analysis framework for CBM Experiment

The Virtual Monte Carlo concept allows performing simulations using Geant3, Geant4 or Fluka without changing the user code. The same framework is then used for the data analysis. An Oracle database with a build-in versioning management is used to efficiently store the detector geometry, materials and parameters. Design and implementation The schematic design of the CBM framework (CbmRoot) is shown in Fig.[1]. Figure 1: Schematic design of the CBM simulation and analysis framework In this design, the framework is fully based on the ROOT system [1].The user can create simulated data and/or perform analysis with the same framework. Moreover, Geant3, Geant4 and Fluka transport engines are supported, however the user code that creates simulated data do not depend on a particular monte carlo engine. Basic functionalities Input/Output procedures The storage of all information collected by the different sensitive detectors is done on an event by event basis (an event means in this context one interaction between one beam particle and the target) . All persistent objects are serialized and stored into binary ROOT files. An interface class (CbmMCPoint ) is provided to define the structure of registered hit in a detector. Each detector can then provide a more specific implementation following the CbmMCPoint API. All registered hits will be collected into dedicated lists, one list corresponding to one detector entity. The ROOT class TTree is used to organize the output data into a ”ntuple like” data structure . In the analysis case, the CbmRootManager provides methods to read this information. A partial input/ouput mechanism is also supported. Parameters definition In order to analyze the simulated data, several numerical parameters are needed, as for example, calibration/digitization parameters or geometry positions of detectors. One common characteristic to most of these parameters is that they will go through several different versions corresponding, for example, to changes in the detectors definition or any other condition. This makes necessary to have a parameter repository with a well-defined versioning system. The runtime database (realized through the CbmRuntimeDb class) is such a repository. Different inputs are supported : Ascii format , ROOT binary format and Oracle Database input. Implementation of the algorithms The analysis (Reconstruction) is organized in tasks. For each event we need to accomplish various tasks or reconstruction algorithms. The CbmTask is an abstract class defining a generic API allowing to execute one task and to navigate through a list of tasks. The user can create his own algorithm inheriting from CbmTask. Each task defines the relevant input data and parameter and creates its particular output data during the initialization phase. During the execution phase, the relevant input data and parameters are retrieved from the input file and the output data objects are stored in the output file.